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REPLY BRIEF 



In response to the new issues raised by the Examiner in the Examiner's Answer, the 
following reply is provided. 

Firstly, under Response to Argument on page 10, the Examiner argues that because an 
"application" is not claimed the applicant's arguments are not relevant. The appellant was 
addressing the argument that the new bandwidth request 518 somehow teaches determining 
whether additional unreserved bandwidth is required. 

The Appeal Brief notes that the request 518 is from a different, additional application. 
Thus, the different application in the reference is not acting "in response to detecting a bit rate 
change event." In other words, the determining whether an additional unreserved bandwidth is 
required is done by an application different from what detects a bit rate change event. This being 
so, it is not seen how, at least in general, it could be deduced that the using of the reserved 
bandwidth for a first portion of the data and using an unreserved bandwidth for a second portion 
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of the data was in response to detecting the bit rate change event. Since two different entities do 
these things, there is no reason to presume that they are communicating with one another and one 
of them precipitates the other. 

The Examiner suggests that the claim does not limit the use of different applications 
executing the same mobile requesting additional bandwidth. While it is true that those words are 
not used, the effect of the words that are used is exactly that. For example, claim 1 calls for a 
controller "to detect a bit rate change event and in response to said event to transmit a first 
portion of the data using reserved bandwidth and a second portion of the data using an 
unreserved bandwidth in response to detecting the bit change event." 

In the cited reference, it is not a controller that is doing both things. It is two 
unconnected applications. It is explained in column 7, lines 5-16 that the communication system 
100 has a gate keeper 112 that keeps or receives a count of the actual slots per second used by an 
application. The gate keeper 1 12 is shown in Figure 1. It is represented as a box separate from 
the web server 114, video server 116, and the storage 110. 

The office action contends that the controller is the item 302. That is shown in the box 
302 in the base site 104. Clearly, it can be seen in Figure 1 that the base site 104 is totally 
separate from the gate keeper 112. It is separated by a communication link 1 10 and routers 108 
as shown in Figure 1. Thus, the conclusion that it is the same controller that does all these things 
is completely unsupportable and is sufficient in and of itself to reverse the rejection. 

The specification of the cited reference at column 5, lines 41-42 indicates that the delay 
sensitive application requirements are sent by the bandwidth manager 500 by an application on 
the wireless terminal 102 shown in Figure 1. These requirements include the bit rate, as the 
Examiner indicates at the bottom of page 5. But just because you tell what your bit rate 
requirements are, you have not created a bit change event, namely, a real time event. You have 
just specified your requirements. It would be akin to a police officer pulling you over for a 
speeding ticket saying I do not know what speed you were going, but I know you are driving a 
car that can go 200 miles an hour. There is a difference between a bit rate change event and a bit 
rate capability. 

The Examiner is making too much about the use of the same two words "bit rate" in very 
different ways, in very different contexts. The suggestion that if the bandwidth is available the 
bandwidth is reserved for the requested bit rate, even if true, does not meet the claimed 
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limitations. There never was the detection of a bit rate change request. The suggestion on page 
6 of the Answer that step 518 determines whether additional bandwidth is required, stating in 
parentheses detecting a bit rate change event, makes no sense. All that is determined is whether 
more bandwidth is required. The bit rate is unchanged and nothing to the contrary is indicated at 
page 7, lines 20-30. Moreover, no change is ever detected, regardless of what is the bandwidth 
that is allocated. The reference simply has little or nothing to do with what is claimed. 

The Examiner argues on page 6 "Hence, the data is transmitted over a first bandwidth . 
(first portion) and if more bandwidth is available, the data is transmitted over additional 
bandwidth (second portion)." If this is what happens, then, certainly, the reference has nothing 
to do with what is claimed. By the Examiner's own admission, data is transmitted over one 
bandwidth and over a second bandwidth if available. But the claim requires detection of a bit 
rate change event that precipitates the transmitting of a first portion over one bandwidth or a 
second portion over a second bandwidth. Here, the Examiner concedes that availability is what 
drives the transmission, not the detection of a bit rate change. This admission also would in and 
of itself justify reversal. 

In view of these remarks, the rejection should be reversed. 
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